Method and system for enforcing security polices in manets

ABSTRACT

A method of enforcing security policies in a mobile ad-hoc network, includes: entrusting at least one first network node along a data traffic route from a data traffic origin node to a data traffic destination node, with the enforcing of predefined security policies on the data traffic; and entrusting at least one second network node, distinct from said first network node, with the control of the enforcement of the security policies by the first network node.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to the field oftelecommunications, and particularly to Mobile Ad-hoc NETworks (MANETs).Even more particularly, the invention relates to the implementation andenforcing of security policies in MANETs. Specifically, the inventionconcerns a method and a system adapted to detect and react to situationswherein the enforcement of security policies set forth for a MANET ismissing or improper.

2. Description of the Related Art

The heterogeneous nature and the mobility characteristics of a MANETmakes it particularly difficult to control the behavior of the nodesthat make up the network.

Nowadays, the acceptance of one or more network security rules by ageneric MANET node as a condition for allowing the node accessing andbecoming part of the network does not prevent that node from violatingsaid rules later, and thus escaping from the control upon it. A nodethat, after an authentication procedure, has been granted access to anad-hoc network is potentially able to perform any action, such as stopproperly routing traffic received from and directed to other MANETnodes, allowing access to services to which some node is not authorized,allowing access to other nodes by revealing the necessary securityinformation, like the ciphering keys.

For these reasons, distributed security mechanisms need to be definedfor MANETs, aiming at making it more difficult to corrupt the networknodes.

The problem of the enforcement of security policies in ad-hoc networkshas already been addressed.

For example, in the thesis work “Adaptive distributed firewall usingintrusion detection” of L. Strand of the Oslo University, reference ismade to a distributed firewalling architecture in which a master (amanagement station) distributes the security policies to clients, whichare the nodes making up the network; the clients apply the securitypolicies and notify the master of the results of the security policiesapplication.

The described architecture is not expressly conceived for MANETs, butthe latter is one of the environments considered as a possibleapplication. The interaction with a distributed intrusion detectionsystem is also considered, which, in case of necessity, allows tocommand a reconfiguration of the firewall of a certain node.

In J. Grant et al. “Distributed firewall technology”, Signal 9 SolutionsInc., 2000, a distributed firewalling architecture is considered whereina Distributed Firewall Server (DFS) distributes the security policies,valid for a certain network, to all the clients belonging thereto(possibly in a personalized way). Each client, in normal operation,creates locally log files of its operation (also related to possiblemalfunctioning of the firewall) and of the traffic passing through thatnode; the logged data are then sent to the DFS, that correlates them fordetecting possible inconsistencies with respect to the security policiesdeployed. The DFS, if possible, may also attempt to sniff the traffic,to check the proper implementation of the security policies deployed.

A different approach is described in S. Rajavaram et al., “Neighboringwatch: an intrusion detection and response protocol for mobile ad-hocnetworks”, University of Maryland, October 2002, where an architecturefor detecting intrusions and anomalous behavior of the nodes belongingto a MANET is discussed. The possibility is exploited that a client(controller) being in the neighbourhood of other nodes “listens”, overthe wireless link, to the communications of said neighbouring nodes, soas to determine the presence of undesired or non-compliant traffic. Thedetection is made individually by every client, and the (possible)countermeasures may be applied locally, in a passive way, by exclusionof the malicious node from the announcements performed by the controllerwith the routing protocol, or in active way, notifying the violation toa master-cluster station that sets-up an election system involving allthe MANET nodes for deciding together whether or not to exclude acertain client.

SUMMARY OF THE INVENTION

The Applicant has observed that the adoption of a distributed securitymechanism is not, per-se, sufficient to ensure that each network nodebehaves properly. Moreover, from the viewpoint of a networkoperator/administrator, the adoption of a totally distributed securitymechanism may be unacceptable, because incompatible with the networkcontrol capability that an administrator may want to have.

In the work of L. Strand, there is no real and reliable way ofcontrolling the application of the security policies. From one hand, itis stated that it is the network node applying the policies that has tonotify to the management station whether the policy application wassuccessful: regretfully, if that node is corrupted, or pursues differentplans, it may send to the management station false information. From theother hand, even if a distributed intrusion detection mechanism isenvisaged, which might affect the firewall reconfiguration on the nodes,nothing is said about how this could be done; moreover, it seems thatthe proposed way is to employ the intrusion detection system to revealclassic intrusions, instead of controlling the proper application of thefirewalling rules.

In the work of J. Grant et al., which is not expressly conceived forMANETs, no efficient method of control of the security policies appliedby the different clients is provided. The proposed solution relies inpart on the communications between the clients and the DFS, but thereported data might be totally false. Also in respect of the envisagedpossibility that the DFS directly sniffs the traffic for controlling theproper application of the policies, it is not explained how this couldbe done; moreover, within a MANET it is practically impossible that asingle station, even if located within the MANET, can intercept all thenetwork traffic, because in a wireless network any station may at mostlisten to the traffic passing within its radio range.

In the work of S. Rajavaram et al., the detection of anomalous behaviorsis not focused on the control of the implementation of firewallingpolicies, rather on the generic control of a node. No mechanism isdescribed for the selection of the nodes to be controlled by acontroller node: this means that a node controls all the clients withinits radio range, without limitations, but this might cause a great wasteof the controller node's resources. Additionally, the proposedarchitecture does not envisage the presence of a real management nodethat tracks the overall behavior of the network.

The Applicant believes that there is the need of providing, for MANETsmanaged by a network operator/administrator, security mechanisms capableof exercising a control on the behavior of the network nodes, and alsocapable of allowing to check the proper application of the securitypolicies intended to be implemented.

The Applicant has found that this need can be satisfied by means of asecurity mechanism which is based, from one side, on the centralizationof the control mechanisms, through which the network is coordinated andmanaged, and, from another side, on the distribution of the securityfunctions across the different network nodes.

In particular, the security mechanism according to an embodiment of thepresent invention allows to control the proper application, by everynetwork node, of the security policies set forth by a networkadministrator, and to identify possible violations. This is achieved byentrusting the nodes of the network with the task of controlling theenforcement of the security policies, in order to detect cases ofviolations/improper enforcement of the security policies by othernetwork nodes, and to identify the network nodes that are responsible ofthe security policies misapplication.

By distributing the control function to several, potentially all thenetwork nodes, the data processing burden on the generic node isreduced, and the performance is thus improved, avoiding at the same timethe formation of malicious “agreements” between network nodes, whichcould make the control vain; the overall network security is thusincreased.

Essentially, the present invention proposes a mechanism for identifyingthe network nodes that are eligible for being controlled:advantageously, these nodes are a subset of the nodes of the network,and particularly they are the nodes that, due to the network topology,have the task of routing traffic from/to other network nodes.

In turn, the nodes that will have to perform the task of controllers areidentified by an interaction with the routing protocol, designed toreduce, as far as possible, the number of nodes to be controlled by eachcontroller node. Indeed, to verify the proper application of thesecurity policies defined for the MANET, particularly to detectunauthorized traffic, each node should monitor all the traffic involvingthe nodes that are within its radio range, but this would imply asubstantial waste of resources (particularly energy, which in mobile,wireless nodes is always precious). According to an embodiment of thepresent invention, the number of controls to be carried out issignificantly limited, by properly choosing the nodes to be controlled,to the extent that, at best, a node may continuously control just asingle other node. Advantageously, a generic node may in general becontrolled by more than one controller nodes (depending on the networktopology).

The controller nodes are able to identify which node(s) has not properlyenforced the security policies, as well as which node(s) violated thesecurity policies, exploiting the missing enforcement of the securitypolicies by network nodes that are entrusted with the enforcementthereof on the violator node.

The invention also provides for countermeasures to be taken once one ormore nodes have been identified that violated or did not enforce thesecurity policies.

Further, according to an embodiment of the present invention, selfishnetwork nodes may be identified (and contrasting actions can accordinglybe taken), i.e. nodes that tend to participate to the MANET in autilitarian way, propagating only their own data packets, and notforwarding (discarding) data packets originated by, and addressed toother nodes.

According to an aspect of the present invention, a method of enforcingsecurity policies in a mobile ad-hoc network is provided, comprising:

-   -   entrusting at least one first network node, along a data traffic        route from a data traffic origin node to a data traffic        destination node, with the enforcing of predefined security        policies on said data traffic:    -   entrusting at least one second network node, distinct from said        first network node, with the control of the enforcement of the        security policies by said first network node.

According to another aspect of the present invention, a system forenforcing security policies in a mobile ad-hoc network, comprising:

-   -   at least one first network node, along a data traffic route from        a data traffic origin node to a data traffic destination node,        entrusted with the enforcing of predefined security policies on        said data traffic:    -   at least one second network node, distinct from said first        network node, entrusted with the control of the enforcement of        the security policies by said first network node.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will resultapparent by reading the following detailed description of an embodimentthereof, provided merely by way of non-limitative example, and referringto the annexed drawings, wherein:

FIG. 1 pictorially shows a scenario of a MANET where the presentinvention can be applied;

FIG. 2 schematically shows network elements implementing a DistributedFirewall Control (DFC) architecture, according to an embodiment of thepresent invention;

FIG. 3 describes a format of HELLO messages exploited by a routingprotocol adopted in the MANET;

FIG. 4 schematically shows an example of application of a DFC mechanismimplemented by the DFC architecture of FIG. 2;

FIG. 5A shows a format of Topology Control (TC) messages used by therouting protocol;

FIG. 5B schematically shows the information that a DFC client of the DFCarchitecture maintains in order to detect the nodes whose behavior isnot compliant to MANET security policies;

FIG. 5C schematically shows the information included in a routing tablekept by a DFC client;

FIG. 6 schematically shows a DFC selection mechanism in case of a loop;

FIG. 7 is a schematic flowchart of a node identification mechanism foridentifying the network node that has not enforced the prescribedsecurity policies, according to an embodiment of the present invention;

FIGS. 8A to 8F schematically show examples of the identification ofnodes that have not enforced the security policies;

FIG. 9 is a schematic flowchart of a node quarantine mechanism accordingto an embodiment of the present invention;

FIGS. 10A and 10B are schematic flowcharts of a process of management ofalarm messages used in the DFC architecture, according to an embodimentof the present invention;

FIG. 11 schematically shows a content of a notification alarm messageused in an embodiment of the present invention;

FIG. 12 schematically shows a content of a quarantine alarm message usedin an embodiment of the present invention;

FIG. 13 schematically shows a content of an alert alarm message used inan embodiment of the present invention;

FIGS. 14A and 14B show a content of global repair request and acceptalarm messages used in an embodiment of the present invention;

FIG. 15 describes an architecture of a selfish node detection mechanismaccording to an embodiment of the present invention; and

FIG. 16 shows a content of a selfish node quarantine message used in anembodiment of the present invention;

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT OF THE INVENTION

In FIG. 1, a scenario in which the present invention is advantageouslyapplied is schematically shown. In the drawing, reference numeral 100denotes a MANET comprising a plurality of mobile network nodes 105, inwireless communications relationship, where the generic network node 105communicates with other network nodes through neighbouring network nodes105 that, at a certain moment, fall within its radio range. In thedrawing, two nodes that are in direct connection with one another aredepicted as connected by a dashed line. Since in general two networknodes cannot in direct connection, because they cannot fall within theirrespective radio ranges, each node 105 of the MANET acts not only as atraffic originator and/or a traffic destination, but also as a trafficrouter, routing traffic from/to other nodes of the network. Thus, evenif the radio range of the network nodes is relatively limited, thenetwork can cover a wide area, because nodes that are not directlyinterconnected can nevertheless communicate with each other via amulti-hop transmission.

Reference numeral 110 denotes a functional entity, like a server,connected to the MANET 100 through an infrastructured network 115, andconfigured to centrally manage the deployment to, and implementation ofsecurity policies in the MANET nodes 105. The infrastructured networkmay include one or more Public Switched Telephone Network (PSTN) and/orone or more mobile telephony networks like GPRS or UMTS networks; thenature and type of the infrastructured network 115 is per-se notlimitative to the present invention. The MANET 100 may in particularconstitute an “extension” of the infrastructured network 115, by meansof which services offered by the network operator to users of theinfrastructured network 115 can also be offered to users of the mobilenetwork nodes 105. The MANET 100 may also operate as a replacement ofthe infrastructured network 115 in case of failure of the latter.

In particular, the server 110 may be managed by an administrator of theMANET 100, for example an administrator operating on behalf of theoperator of the infrastructured network 115 MANET 100. By means of theserver 110, the network administrator keeps a control on the trafficexchanged through the MANET 100, defining security policies to beapplied by the MANET nodes 105; the security policies may for example bedeployed dynamically via the infrastructured network 115 and the MANET100.

According to the present invention, it is ensured that the desiredsecurity policies are effectively applied and respected, i.e. that thesecurity policies are enforced.

According to an embodiment of the present invention, a DistributedFirewalling Architecture (DFA) is implemented in the MANET 100, adaptedto set-up a distributed firewalling mechanism, according to which thefirewalling operations are entrusted to the MANET nodes 105. The genericMANET node 105 behaves as a client (hereinafter referred to as aDistributed Firewalling Architecture client or, shortly, “DFA client”)in respect of the server 110 (hereinafter referred to as the “DFAserver”). The client resident in the generic MANET node 105,schematically depicted in the drawing and denoted 120, is adapted todynamically receive from the DFA server 110 security policies to beapplied in the MANET, to interpret the received security policies and totranslate them into lower-level traffic filtering rules (e.g., InternetProtocol—IP—filtering rules), used for filtering the traffic that isrouted by the MANET nodes, as will be described in detail later.

According to an embodiment of the present invention, the generic MANETnode 105 does not filter its own traffic, i.e. the traffic it originatesor that is destined thereto, rather it filters the traffic of the otherMANET nodes, particularly of the neighbouring MANET nodes; in otherwords, considering the generic MANET node 105, its traffic is filteredby one or more of the neighbouring MANET nodes.

In particular, according to an embodiment of the present invention, anefficient traffic filtering policy is implemented, which provides forentrusting the network traffic filtering operation to a subset of MANETnodes, particularly to the neighbouring nodes of a node that is eitherthe source of the data traffic or the destination of the data traffic.In this way, it is avoided that every MANET node has to apply thesecurity policies, i.e. the data traffic filtering rules valid for allthe MANET nodes, and has to compare to such rules every data packetreceived before routing it. In other words, according to an embodimentof the present invention, the filtering of a data packet sent by acertain source or origin node, like the network node denoted 105 s inFIG. 1, towards a certain destination, like the network node 105 d inthe drawing, is carried out only by the (DFA client resident on the)node 105 a that, along the route 125 followed by the data packet,immediately follows the source node, and by the node 105 b that, alongsaid route, immediately precedes the destination node.

In particular, in an embodiment of the present invention, indicationsabout the network topology are exploited to identify which MANET nodeshave to filter the data traffic; in particular, said network topologyindications are included in and propagated by routing messages fromwhich the generic DFA client 120 can derive, in real time, which are theMANET nodes with which it can communicate. In particular, the knowledgeof the distance from each node, in terms of number of hops, enables theDFA client 120 resident on the generic MANET node 105 to classify thenodes of the MANET as neighbouring nodes and distant nodes; for thepurposes of the present description and claims, by “neighbouring node”it is meant a MANET node that is one hop distant from the generic node,whereas by “distant node” it is meant a MANET node more than one hopdistant from the generic node. In this way, the DFA client 120 residenton the generic MANET node 105 is adapted to dynamically configureitself, adding and/or removing security policy rules based on thechanges in the network topology, and actuating only the rules that areassociated with the nodes it knows, i.e. its neighbouring nodes.

Entrusting the enforcement of the security policies defined in respectof a certain MANET node 105, like for example the node 105 s in FIG. 1,to the (DFA client 120 resident on the) neighbouring nodes, i.e. thenode 105 a in the example of FIG. 1, avoids that the remaining,successive nodes on the route 125 followed by a data packet sent by thenode 105 s (like the node 105 c in the shown example) have to performfiltering operations on the same data traffic, because this filteringoperation is useless, since assumed that the filtering has been made bythe node 105 a the traffic inherently complies with the prescribedsecurity policies.

The further filtering entrusted to the node that, like the node 105 b inthe example of FIG. 1, immediately precedes the data packet destinationnode 105 d is not essential, but it increases the overall networksecurity.

In addition to the distributed firewalling architecture and mechanismdescribed above, according to an embodiment of the present invention, adistributed firewall control architecture is implemented in the MANET100, adapted to set-up a distributed control mechanism for detecting thepresence, in the MANET 100, of traffic not compliant with a certainsecurity policy, and, in case such non-compliant traffic is detected, toidentify the node(s) which has not properly enforced the securitypolicy, as well as to identify the node(s) that violated the securitypolicy, and to consequently take proper countermeasures. The distributedcontrol mechanism allows avoiding that unauthorized traffic, generatedby a node that violated the security policies, and not properly filteredby the client DFA on the node entrusted with the security policiesenforcement (the node that immediately follows the source node), isrouted through several network nodes before being filtered out, forexample by the node that immediately precedes the destination node, witha consequent saving of network nodes' power and bandwidth resources.

According to an embodiment of the present invention, as schematicallyshown in FIG. 2, the distributed firewall control architecture comprisesa distributed firewall control server (hereinafter shortly referred toas “DFC server”) 205, possibly, albeit not limitatively, co-located withthe DFA server 110. The DFC server 205 is configured to centrally manageand coordinate a distributed firewall control mechanism, taking propercountermeasures in respect of MANET nodes that do not properly enforcethe security policies and nodes that violate the security policiesdefined for the MANET; the DFC server 205 interacts with the DFA server110 and, possibly, with further entities forming a security platform ofthe MANET, like for example one or more authentication servers 210.

Like in the scenario of FIG. 1, each MANET node 105 acts as a client(DFA client) of the DFA server 110, i.e. as an enforcer of thefirewalling policies defined for the nodes that, at a certain time, areits neighbours. In addition to the DFA client, a DFC client 215 isresident on each MANET node 105, adapted to detect the properapplication of the security policies by the DFA clients, i.e. by thesecurity policies enforcers.

Additionally, on the generic MANET node 105 one or more applicationsdesigned to implement the desired routing protocol are assumed to beresident (not shown in the drawing), adapted to set up the data packetsroutes for reaching nodes that are distant more than one hop. Inparticular, said routing protocol is assumed to be a proactive routingprotocol. As known to those skilled in the art, routing protocolsdefined for MANETs are generally classified as proactive protocols andreactive protocols, depending on how the routes towards the destinationnodes are determined; in proactive protocols, every node periodicallypropagates to the network its topological information so that each nodein the MANET is able to build the network map and to calculate a path toreach every node. With reactive protocols, the generic node calculates apath towards another node only at the time the former node has to senddata to the latter node.

In particular, according to an embodiment of the present invention, therouting protocol adopted is the Optimized Link State Routing (OLSR)protocol, described for example in T. Clausen, P. Jacquet, “OptimizedLink State Routing Protocol (OLSR)”, RFC 3626, October 2003. The OLSRprotocol uses a broadcast algorithm exploiting a subset of the MANETnodes 105, referred to as the MultiPoint Relay (MPR), specifically forthe propagation of the routing messages. Each node that implements theOLSR routing protocol builds its own set of MPR nodes (the “MPR set”),by means of a procedure called “neighbour detection”, and getsindications about the lists of nodes that are distant one or two hopstherefrom; then, the considered node elects as MPR node one of theneighbouring nodes with which there is a bidirectional link (a“symmetric neighbour”), which allows the considered node to reachanother node distant two hops. In this way, the union of the areascovered by the radio ranges of all the MPR nodes elected by one genericnode covers all the nodes that are distant two hops therefrom. Each nodesends to its neighbouring nodes the respective set of elected MPR nodesthrough particular OLSR protocol messages, referred to as “HELLO”messages; the structure of a HELLO message is pictorially shown in FIG.3. The HELLO message, globally denoted 300, includes one or more fields305 called “Neighbour Interface Address”, wherein each node inserts thenetwork addresses (IP addresses) of its neighbouring nodes, distant onehop, and a field 310 called “Neighbour Type”, wherein each node definesif the node with neighbour interface address is an MPR for it. Forexample, referring to scenario shown in FIG. 4, wherein an exemplarynetwork topology 400 is depicted, node 405 a inserts into the fields 305of the HELLO messages it sends the addresses of nodes 405 b, 405 c, 405d and 405 e; among these nodes, node 405 a elects as MPR node only thenode 405 e, thus, in the HELLO messages, it sets for this node the field310 to a value “MPR_NEIGH”, to indicate that the node 405 e is an MPR.

The nodes that are elected MPR nodes, in addition to sending their ownHELLO messages, periodically send “TOPOLOGY CONTROL” (“TC”) messages;the structure of a TC message is pictorially shown in FIG. 5A: themessage, globally denoted 500, includes a plurality of fields 505 called“Advertised Neighbour Main Address”, each one adapted to contain theaddress of one network node that has elected the considered node as itsMPR. In this way, each network node can build its own routing table: theroutes towards all the possible destinations are calculated passingthrough the MPR nodes elected by each node.

According to an embodiment of the present invention, the firewallcontrol mechanism implemented by the DFC architecture advantageouslyexploits the principles of operation of the OLSR routing protocol andthe correspondingly obtained network topological indications, in orderto limit the number of controls to be performed to a subset of the MANETnodes. In particular, also the MANET data traffic is caused to passthrough the nodes that are elected MPR nodes in respect of the OLSRprotocol. This is achieved by causing every node, when building therespective routing table, to configure as next-hop for reaching adesired destination one of the MPR nodes which have been elected by thatnode. In this way, a first optimization of the DFC mechanism isachieved, that allows performing the firewall control function only onthe MPR nodes, i.e. only on those nodes that actually handle the routingof data traffic from/to the other nodes. The MPR nodes form altogether arelatively small subset of all the MANET nodes (in FIG. 4, the MPR nodesare shown as encircled, and the subset of MPR nodes is denoted 450).Thus, the subset of MPR nodes becomes the set of the DFA clients 120that are subjected to controls in order to guarantee that the securitypolicies defined for the MANET are actually applied and enforced.

Additionally, the DFC client 215 resident on the generic network node isadapted to choose, within the above-mentioned subset 450 of DFA clients120 to be controlled, that or those DFA clients on which to perform thecontrol, by means of a nodes selection mechanism.

According to an embodiment of the present invention, the nodes selectionmechanism enables the generic DFC client 215 to:

-   -   limit the number of controls it has to perform to a small,        possibly the smallest number of DFA clients 120 (ideally, a DFC        client may have to control just one DFA client); and    -   guarantee that the choice of the node to control does not        jeopardize the possibility of controlling a different DFA client        120; in other words, all the DFA clients belonging to the        above-mentioned subset 450 of the MPR nodes should be controlled        by at least one DFC client.

Hereinafter, the DFC mechanism according to an embodiment of the presentinvention is described in detail, applied to the exemplary MANET shownin FIG. 4. It is assumed that the nodes denoted 405 a, 405 e, 405 f, 405g and 405 h (shown as encircled) are the elected MPR nodes elected bythe routing process of the OLSR; the nodes 405 a, 405 e, 405 f, 405 gand 405 h thus represent the subset 450 of the DFA clients 120 that areto be controlled. Each DFC client 215 knows this subset of nodes 405 a,405 e, 405 f, 405 g and 405 h based on the topological indicationsacquired by the routing protocol.

Essentially, the DFC mechanism includes three phases.

In a first phase, based on the subset of nodes thus built, each DFCclient 215 chooses one DFA client 120 (i.e., one node) within the subsetof nodes to be controlled, using the above mentioned selectionmechanism.

A second phase and a third phase, described in detail later on, concernactions to be taken in case it is ascertained that the security policiesare not properly implemented; the actions that, according to anembodiment of the present invention, can be taken are a local repairaction and a global repair action.

In an embodiment of the present invention, the selection mechanismadopted for selecting the DFA clients 120 to be controlled is thefollowing.

Each DFC client 215, residing on a certain network node 105, firstlyassesses the number of MPR nodes that have been elected by the networknode where such DFC client 215 resides.

If the number of elected MPR nodes is equal to 1, then the DFA client tobe controlled is the sole MPR node that has been elected. Referring tothe example of FIG. 4, the node 405 c is assumed to have elected as MPRonly the node 405 a, thus the DFC client 215 resident on node 405 ccontrols the DFA client 120 resident on node 405 a.

If instead the number of elected MPR nodes is greater than 1, the DFCclient 215 assesses whether the node where it resides is involved in aloop, i.e. it is part of a closed path, originating at and terminatingin a same node; in the example depicted in FIG. 6, a loop 600 exists,originating at node 605 a, passing through nodes 605 b, 605 c, 605 d and605 e, and terminating in node 605 a. The assessment of the existence ofloops by the generic DFC client is for example carried out using the MPRselector set transmitted by every MPR node in the TC messages it sends(the MPR selector set is the group of node addresses contained in thefields Advertised Neighbour Main Address 505 of the TC message 500depicted in FIG. 5A); as mentioned in the foregoing, this informationallows building up a path from a certain source node to a certaindestination node.

If the DFC client ascertains that there is a loop originating at andterminating in the node where it resides, like in the case of the DFCclient 215 residing on node 605 a of FIG. 6, then the DFC client 215decrees that the node where it resides is involved in a loop.

In case no loops are identified, the DFC client 215 chooses to control,among the MPR nodes elected by the node where it resides, the MPR nodethrough which the lowest number of nodes distant two hops can bereached. Referring to the example of FIG. 4, let it be assumed that thenode 405 e has elected as MPR the nodes 405 a and 405 f; through thenode 405 a, the node 405 e can reach the nodes 405 b, 405 c and 405 d,distant from it two hops, whereas through the node 405 f it can onlyreach the node 405 g: thus, the DFC client resident on the node 405 echooses to control the DFA client 120 resident on the node 405 f. If twoor more MPR nodes allow reaching the same number of nodes distant twohops, then the DFC client 215 chooses as DFA client to control the oneresident on a node which, in turn, has elected the lowest number of MPRnodes. If even in this way two or more nodes are identified, then thechoice is made randomly. This is for example the case of node 405 f ofFIG. 4, which has elected as MPR nodes the nodes 405 e and 405 g;through the node 405 e, the node 405 f can reach the nodes 405 a, 405 iand 405 m, whereas through the node 405 g it can reach the nodes 405 h,405 n and 405 p, all distant two hops. Not being able to make adiscrimination, between the nodes 405 e and 405 g, then the node 405 flooks which, among the nodes 405 e and 405 g, has elected the lowestnumber of MPR nodes: the node 405 e has elected as MPR nodes the nodes405 a and 405 f, whereas the elected MPR nodes of the node 405 g are thenodes 405 f and 405 h; again, it is not possible to discriminate betweenthe nodes 405 e and 405 g, so the DFC client resident on the node 405 fperforms a random choice, and for example the choice is made of node 405g.

Let now the case be considered that loops exist. In the worst case, foreach DFA client 120 there is only one DFC client 215 that can controlit. It is therefore necessary to avoid that two DFC clients 215 chooseto control a same DFA client 120, otherwise it may happen that thecontrol of (the DFA client 120 resident on) all the nodes in the subset450 of elected MPR nodes is not guaranteed. In this case, the DFC client215 should select the DFA client 120 to control following a certaincontrol direction, denoted 610 in the example of FIG. 6. In particular,according to an embodiment of the present invention, the controldirection is defined by the node, in the loop, having the numericallylowest IP address; for example, making reference to FIG. 6, and assumingthat the IP addresses of the nodes 605 a, 605 b, 605 c, 605 d and 605 eare 210, 212, 214, 216 and 218, the numerically lowest address is 210.In the TC message 500 transmitted by the node 605 a, each DFC client 215identifies the first node 505 a announced in the MPR selector set amongthose making part of the loop. Thus, each DFC client 215 chooses, as DFAclient 120 to control, the one residing on the MPR node that, startingfrom the node where the considered DFC client 215 resides and passingthrough the node in the loop having lowest IP address, allows reachingthe first node 505 announced in the MPR selector set in the TC message.Referring to the example of FIG. 6, a loop 600 exists formed by thenodes 605 a, 605 b, 605 c, 610 d and 610 e; in this case, the node ofthe loop 600 having the lowest IP address is the node 605 a (IPaddress=210), so this node 605 a is the one defining the controldirection to be followed. All the DFC clients 215 resident on the nodesof the loop 600 look at the MPR selector set announced by the node 605 ain the TC messages it sends; in this example, the MPR selector set isassumed to be formed by the nodes 605 e and 605 b, and it is alsoassumed that the node 605 e is the first to be announced in the MPRselector set (this node is also part of the loop). Thus, the controldirection 610 to be followed is the direction that, passing through thenode 605 a (i.e. the node with lowest IP address in the loop), allowsreaching the node 605 e (the first announced node in the MPR selectorset). The DFC client 215 resident on the node 605 c thus chooses tocontrol the DFA client 120 resident on the node 605 b, which allows itto reach the node 605 e passing through the node 605 a; similarly, theDFC client 215 resident on the node 605 d chooses to control the DFAclient 120 resident on the node 605 c, which allows it reaching the node605 e passing through the node 605 a. In this way, each node of the loopis controlled by another node.

Hereinafter, examples of countermeasures that can be taken when it isdetected a violation of the security policies will be described.

Local Repair Mechanism

The local repair mechanism calls for placing in quarantine the networknode where a DFA client 120 resides which has not properly enforced thesecurity policies defined for the MANET. The quarantine has effectlocally to the MANET (i.e. the DFC server 205 is not involved) and it isdirected to temporarily isolate the detected node on which the DFAclient 120 which has not properly enforced the security policiesresides.

In particular, in an embodiment of the present invention, the quarantinemechanism is applied to a generic node a maximum, predetermined numberof times, defined for example by a threshold value: once a node has beenput in quarantine the maximum number of times, a global repair mechanism(described later on) can be applied to that node.

The choice of allowing a DFA client 120 to be put in quarantine morethan once is motivated by the fact that an incorrect enforcement of thesecurity policies might be caused by a temporary misalignement of a DFAclient 120 with the DFA server 110, due for example to an ongoing updateof the security policies, or to a delay of convergence of the routingprotocol, thereby the topological indications used for applying thesecurity policies may not be sufficiently up to date.

Every DFC client 215 performs an active control of the DFA client 120that has been selected for being controlled, by means of a continuousmonitoring of the (entering and exiting) traffic flowing through thenode hosting the controlled DFA client 120, so as to detect cases ofmissed enforcement of the security policies.

Each time a DFC client 215 detects an improper application of thesecurity policies defined for the MANET, it stores data, schematized inFIG. 5B and denoted therein as 507, comprising:

-   -   the IP address (IP_S) 510 of the node originating the data        packets that violate a certain security policy;    -   the IP address (IP_D) 515 of the destination node of those data        packets;    -   the MAC (Media Access Control) address (MAC_in) 520 of the node        originating the incoming traffic entering into the node hosting        the controlled DFA client 120; this MAC address MAC_in        corresponds to the node that has routed the traffic to the node        hosting the DFA client 120 being controlled;    -   the identifier (ID) 525 of the traffic session.

Additionally, every DFC client 215 keeps, for all the MANET nodes, anassociation between the IP address IP_S of the source node and therelated MAC address MAC_S (field 530).

Based on this data, the DFC client 215 starts the local repairprocedure, which calls for:

-   -   identifying the DFA client 120 that has not properly enforced        the security policies; and    -   put in quarantine the network node on which the identified DFA        client 120 resides.

To identify the DFA client 120 that has not properly enforced thesecurity policies, the DFC client 215 exploits the data 507,particularly the MAC address MAC_in 520 of the traffic entering thecontrolled DFA client 120, as well as the routing table; as known tothose skilled in the art, the routing table, schematically depicted inFIG. 5C and denoted therein as 550 is a table that the generic node usesto know how to reach any other network node, and wherein the number ofhop counts necessary to reach the other nodes is specified. Using thedata contained in the routing table 550, the DFC client 215 is capableof determining how far is, in terms of hops number (“hop count”), thesource node, whose address is the IP_S.

The procedure for identifying the DFA client 120 that has not enforcedthe security policies is schematized by the flowchart of FIG. 7.

Firstly, the DFC client searches, in its routing table, the entrycorresponding to the node having address equal to IP_S, i.e. the sourcenode originating the traffic that violated the security policy, so as toderive the corresponding hop count value (block 705).

If the hop count value is equal to 1 (block 710, exit branch Y), thenthe node with address IP_S is directly reachable by the node where theDFC client 215 resides. The DFC client 215 checks whether the MACaddress MAC_in of the traffic entering the controlled DFA client 120coincides with the MAC address MAC_S of the source node (block 715). Inthe affirmative case (exit branch Y of block 715), the (node hostingthe) controlled DFA client 120 is thus responsible of the securitypolicies violation (i.e., it is the security policy violator node): theDFC client 215, being the next hop in respect of the security policiesviolator node, puts the latter node in quarantine (block 720).

Considering the exemplary situation depicted in FIG. 8A, let the trafficoriginated by node 805 a and destined to node 805 b be considered, andlet it be assumed that the node 805 a is not authorized, by the securitypolicies defined for the MANET, to generate such traffic. In such acase, the node 805 c, is a direct neighbour of the source node 805 a,and the node 805 d is a direct neighbour of the destination node 805 b.The two nodes 805 c and 805 d are responsible of enforcing the securitypolicies, blocking the traffic generated by the node 805 a. Let it beassumed that the DFA client 120 resident on the node 805 c does notenforce the security policies, and lets the traffic originated by thenode 805 a pass through. The DFA client 120 resident on the node 805 cis thus the security policies violator, which should be identified bythe DFC mechanism. Let it be assumed that the DFC client 215 resident ona node 805 e is the controller of the DFA client 120 hosted by the node805 c: inspecting the traffic exiting the node 805 c, the DFC client 215hosted by the node 805 e is able to detect that the traffic having IP_Sequal to that of the node 805 a is not authorized in the MANET. Lookingat its routing table, the DFC client 215 hosted by node 805 e determinesthat the hop count value for the node 805 a is equal to 1, and that theMAC address MAC_in of the traffic entering the controlled DFA client 120hosted by node 805 c coincides with the MAC address MAC_S of the sourcenode 805 a. Thus, the DFC client 215 hosted by node 805 e determinesthat the controlled DFA client 120 has not enforced the securitypolicies, and it is a security policies violator: being the controllernode 805 e a direct neighbour of the violator node 805 c, the controllernode 805 e directly puts the violator node 805 c in quarantine.

Referring back to FIG. 7, if the two MAC addresses MAC_in and MAC_S donot coincide (exit branch N of block 715), the DFA client 120 that hasnot enforced the security policies resides on the node that, along theroute from the source node (IP address IP_S) to the destination node (IPaddress IP_D) precedes the controlled DFA client 120, i.e. on the nodewhose MAC address is MAC_in (in fact, the node responsible of enforcingthe security policies is the next hop of the source node, with IPaddress IP_S, so it cannot be the controlled DFA client 120, because thelatter is distant two hops). The DFC client 215, not being the next-hopof the security policies violator node, does not directly put theviolator node in quarantine: it instead broadcasts an alarm signal,particularly a NOTIFICATION message (block 725), described in detaillater on, for notifying to the other MANET nodes that the identified DFAclient 120 has not properly enforced the security policies, for askingthe neighbouring nodes to put the violator node in quarantine, and forasking the nodes that are along the route from the source node to thedestination node to temporarily apply the violated security policies.

Considering the exemplary situation depicted in FIG. 8B, let the trafficoriginated by the source node 805 a and destined to the destination node805 b be considered, assuming that the node 805 a is not authorized, bythe security policies defined for the MANET, to generate such traffic.Node 805 c is a direct neighbour of the source node 805 a, and node 805d is a direct neighbour of the destination node 805 b: the two nodes 805c and 805 d are thus responsible of enforcing the security policies,blocking the traffic generated by the node 805 a. Let it be assumed thatthe DFA client 120 resident on node 805 c does not enforce the securitypolicies, and lets the traffic originated by node 805 a pass through;the node 805 c is thus the security policies violator, that should beidentified by the DFC mechanism. The DFC client 215 resident on node 805f is the controller of the DFA client 120 resident on node 805 g.Inspecting the traffic leaving node 805 g, the DFC client 215 residenton node 805 f detects that the traffic source IP address IP_Scorresponding to the IP address of the source node 805 a is notauthorized in the MANET. Based on its routing table, the DFC client 215resident on node 805 f derives that the hop count value for the sourcenode 805 a is equal to 1, but the MAC address MAC_in of the trafficentering the controlled DFA 120 client resident on node 805 g differsfrom the MAC address MAC_S of the source node 805 a. Thus, the DFAclient 120 that has not enforced the security policies resides on thenode having MAC address equal to MAC_in, i.e. on the node 805 c. The DFCclient 215 resident on the node 805 f cannot directly put in quarantinethe violator node 805 c, thus it broadcasts a NOTIFICATION alarmmessage.

Referring back again to FIG. 7, if the hop count is not equal to 1 (exitbranch N of block 710), the DFC client 215 ascertains whether the hopcount value is equal to 2 (block 730).

If the hop count value is equal to 2 (exit branch Y of block 730), thenthe source node originating the traffic in violation of the securitypolicies is not directly reachable by the DFC client 215. The DFC client215 then checks if the MAC address MAC_in of the traffic entering thecontrolled DFA client 120 coincides with the MAC address MAC_S of thesource node (block 735). In the affirmative case (exit branch Y of block735), the DFA client 120 controlled by the considered DFC client 215 isresponsible of the security policies violation, i.e. it is the violatornode. The DFC client 215, being in this case a next hop of the violatornode, directly puts the violator node in quarantine (block 720).

Referring to the exemplary scenario depicted in FIG. 8C, let the trafficoriginated by source node 805 a and destined to the destination node 805b be considered, and let it be assumed that the source node 805 a is notauthorized, based on the security policies valid for the MANET, togenerate such traffic. In this situation, node 805 c is a directneighbour of the source node 805 a, and node 805 d is a direct neighbourof the destination node 805 b. The two nodes 805 c and 805 d are thusresponsible of the enforcement of the security policies, blocking thetraffic generated by the source node 805 a. Let it be assumed that theDFA client 120 resident on the node 805 c does not enforce the securitypolicies, letting the traffic originated by the source node 805 a passthrough: the (DFA client 120 on) node 805 c is thus the securitypolicies violator, that should be identified by the DFC mechanism. TheDFC client 215 resident on node 805 h is one of the controllers of theDFA client 120 on node 805 c. Inspecting the traffic exiting the node805 c, the DFC client 215 resident on node 805 h detects that thetraffic with source IP address IP_S equal to the IP address of thesource node 805 a is not authorized in the MANET. Looking at its routingtable, the DFC client 215 resident on node 805 h derives that the hopcount value for the source node 805 a is equal to 2, and that the MACaddress MAC_in of the traffic entering the controlled node 805 ccoincides with the MAC address MAC_S of the source node 805 a. Thus, theDFA client 120 resident on node 805 c controlled by the DFC client 215resident on node 805 h has not enforced the security policies, and node805 c is the violator; since the controller node 805 h is a next-hop ofthe violator node 805 c, the DFC client 215 resident on node 805 hdirectly puts the violator node 805 c in quarantine.

Back to FIG. 7, if the two MAC addresses MAC_in and MAC_S do notcoincide (exit branch N of block 735), the DFC client 215 checks if theIP address IP_S of the source node is included in the MPR selector setannounced in the TC messages issued by the node having the MAC addressMAC_in of the traffic entering the controlled node (block 740).

In the affirmative case (exit branch Y of block 740), the securitypolicy violator node is the node which, along the route from the sourcenode (with IP address IP_S) to the destination node (with IP addressIP_D), precedes the controlled node, i.e. the node having MAC addressequal to MAC_in. In such a case, the considered DFC client 215, notbeing the next hop of the violator node, cannot directly put the latterin quarantine, so the DFC client 215 broadcasts a NOTIFICATION alarmmessage (block 725), concerning the violator node.

Referring to the exemplary scenario shown in FIG. 8D, let it be assumedthat there is a traffic flow originating from the source node 805 a anddirected to the destination node 805 b, assuming that the node 805 a isnot authorized, by the security policies defined for the MANET, tooriginate such traffic. Node 805 c is a direct neighbour of the sourcenode 805 a, and node 805 d is a direct neighbour of the destination node805 b; the nodes 805 c and 805 d are thus responsible of enforcing thesecurity policies, blocking the traffic generated by the source node 805a. It is assumed that the DFA client 120 resident on node 805 c does notenforce the security policies, letting the traffic coming from thesource node 805 a pass through; the node 805 c is thus a securitypolicies violator that has to be identified by the DFC mechanism. TheDFC client 215 resident on node 805 i is the controller of DFA client120 resident on the node 805 m. Inspecting the traffic exiting the node805 m, the DFC client 215 resident on node 805 i detects that thetraffic with IP address corresponding to the address IP_S of the sourcenode 805 a is not authorized. Based on its routing table, the DFC client215 determines that the hop count value for the source node 805 a isequal to 2, and that the MAC address MAC_in of the traffic entering thenode 805 m does not coincide with the MAC address MAC_S of the sourcenode 805 a, being instead the MAC address of the node 805 c. Thecontroller node 805 i checks whether, in the TC messages sent by thenode 805 c, the IP address IP_S of the source node 805 a is included inthe MPR selector set: thus, the DFA client 120 that has not enforced thesecurity policies (the security policies violator) resides on node 805c. In such a case, the node 805 i, not being a direct neighbour of thesecurity policies violator node, broadcasts a NOTIFICATION alarmmessage.

Back to FIG. 7, if the IP address IP_S of the source node originatingthe traffic is not included in the MPR selector set (exit branch N ofblock 740) announced by the node with MAC address equal to MAC_in, thenthe DFC client 215 ascertains whether its MAC address coincides with theMAC address MAC_in of the traffic entering the controlled DFA client 120(block 745). If the two addresses coincides (exit branch Y of block745), the DFA client 120 that has not enforced the security policiesresides on the node that precedes the node hosting the DFC client 215along the route from the source node (IP address IP_S) to thedestination node (IP address IP_D), and thus said DFA client 120 resideson a neighbouring node (a next hop) of the node where the DFC client 215resides. In order to identify which of its neighbours has not enforcedthe security policies, the DFC client 215 searches, in the MPR selectorset included in the TC messages sent by its neighbours, the IP addressIP_S of the source node (block 750). Then, if the IP address IP_S isfound, the DFC client 215 checks how many of its neighbours announce theIP address IP_S in their MPR selector set: if only one of the neighboursannounces the IP address IP_S in its MPR selector set (exit branch Y ofblock 755), then such neighbour is the node where the DFA client 120that violated the security policies resides: the DFC client 215,residing on a node that is a next-hop of the violator node, directlyputs the latter node in quarantine (block 720); if instead more than oneof the neighbour nodes announces the IP address IP_S, then the DFCclient 215, not being able to identify which is the node where the DFAclient 120 that violated the security policies resides, broadcasts analarm message, particularly an ALERT message (block 760).

Considering the exemplary scenario depicted in FIG. 8E, let the trafficoriginated by the source node 805 a and destined to node 805 b beconsidered, assuming that the node 805 a is not authorized, by thesecurity policies defined for the MANET, to generate such traffic. Node805 c is a direct neighbour of the source node 805 a, and node 805 d isa direct neighbour of the destination node 805 b. The two nodes 805 cand 805 d are thus responsible of enforcing the security policies,blocking the traffic generated by the node 805 a. Let it be assumed thatthe DFA client 120 resident on node 805 c does not enforce the securitypolicies, letting the traffic originated by node 805 a pass through: theDFA client 120 resident on node 805 c is thus the security policiesviolator, that should be identified by the DFC mechanism. The DFC client215 resident on node 805 n is the controller of the DFA client 120resident on node 805 p; monitoring the traffic on node 805 p, the DFCclient 215 resident on node 805 n detects that the traffic having IPaddress equal to the IP address IP_S of the source node 805 a is notauthorized. Based on its routing table, the DFC client 215 derives thatthe hop count for node 805 a is equal to 2, and that the MAC addressMAC_in of the traffic entering the controlled DFA client 120 resident onnode 805 p coincides with its own MAC address. In this case, thecontroller node 805 n can decree that the DFA client 120 violating thesecurity policies resides on one of its neighbours, particularly on thepreceding node along the route from the source node to the destinationnode. In order to identify which is the violator node, among itsneighbours 805 q, 805 c, 805 r, the DFC client 215 resident on thecontroller node 805 n checks whether, in the TC messages sent by theneighbour nodes, there is the IP address IP_S of the source node 805 a.The nodes 805 q and 805 r, not being MPR nodes, do not send TC messages(in the drawing, the nodes that have been elected as MPR nodes areencircled). In the considered example, only the node 805 c sends TCmessages containing the IP address IP_S of the source node 805 a, thusthe DFA client 120 that has not enforced the security policies resideson node 805 c; the node 805 n, being a direct neighbour thereof,directly puts the violator node 805 c in quarantine.

Back to FIG. 7, if the hop count is different from 2 (exit branch N ofblock 730), the DFC client 215 checks whether the hop count is equal to3 (block 765).

In the affirmative case (exit branch Y of block 765), the DFA client 120that violated the security policies is not the one controlled by theconsidered DFC client 215. The DFC client 215 checks if the IP addressIP_S of the source node is included in the MPR selector set announced inthe TC messages sent by the node having MAC address equal to MAC_in,i.e. the MAC address of the traffic entering the DFA client 120controlled by the DFC client 215 considered (block 770). In theaffirmative case (exit branch Y of block 770), the DFA client 120 thatviolated the security policies resides on the node that, along the routefrom the source node (IP address equal to IP_S) to the destination node(IP address equal to IP_D), precedes the node hosting the controlled DFAclient 120, i.e. the violator node is the node having MAC address equalto MAC_in. In this case, the DFC client 215 is not a next-hop of theviolator node, and cannot directly put the violator node in quarantine;the DFC client 215 thus broadcasts an alarm message, particularly aNOTIFICATION message (block 725) related to the violator node.

Looking at the exemplary scenario depicted in FIG. 8F, let the trafficoriginating from source node 805 a and destined to destination node 805b be considered, and let it be assumed that the source node 805 a is notauthorized, by the security policies defined for the MANET, to generatesuch traffic. Node 805 c is a direct neighbour of the source node 805 a,and node 805 d is a direct neighbour of the destination node 805 b; thetwo nodes 805 c and 805 d are responsible of enforcing the securitypolicies, blocking the traffic generated by the node 805 a. It isassumed that the DFA client 120 resident on node 805 c does not enforcethe security policies, letting the traffic generated by the source node805 a pass through: the node 805 c is thus the security policiesviolator, that should be identified by the DFC mechanism. The DFC client215 resident on node 805 r is the controller of the DFA client 120resident on node 805 s. Monitoring the traffic on node 805 s, the DFCclient 215 resident on node 805 r detects that the traffic with IPaddress equal to that (IP_S) of the source node 805 a is not authorized;based on its routing table, the DFC client 215 resident on node 805 rdetermines that the hop count for the source node 805 a is equal to 3;the DFC client 215 also checks if the IP address of the source node 805a is included in the MPR selector set announced in the TC messages sentby the node having MAC address MAC_in, from which the traffic enteringthe controlled node 805 s comes. The violator node 805 c, having MACaddress MAC_in, is thus the node that precedes the controlled node 805s. The DFC client 215 resident on node 805 r is not a next-hop of theviolator node 805 c, thus it cannot directly put the violator node inquarantine: the node 805 r then broadcasts an alarm message,particularly a NOTIFICATION message related to the violator node 805 c.

Back to FIG. 7, if the IP address IP_S of the source node is notincluded in the MPR selector set announced in the TC messages of thenode having MAC address equal to the MAC address MAC_in of the trafficentering the DFA client 120 controlled by the DFC client 215 considered(exit branch N of block 770), the DFC client 120 is not able to identifythe violator node, and thus simply issues an ALERT message (block 760).

If the hop count is higher than 3 (exit branch N of block 765), the DFAclient 120 that did not enforce the security policies is not thatresident on the node controlled by the DFC client 215, neither does itreside on the node that precedes the node where the DFA client 120controlled by the considered DFC client 215 resides, along the routefrom the source node to the destination node. In this case, the DFCclient 215, not being able to determine which is the DFA client 120 thatviolated the security policies, performs no control on the MAC addressMAC_in, and directly broadcasts an alarm message, particularly an ALERTmessage (block 760). However, the DFA client 120 that did not enforcethe security policies has in this case already been identified by themonitoring action performed by the nodes distant 1 or 2 hops from thesource node; in fact, the filtering is performed only by the neighbournodes of the node originating the unauthorized traffic. The control ofthe nodes more distant than 2 hops, which are not responsible ofenforcing the security policies in respect of the source node, isscarcely useful for identifying the DFA client 120 that did not enforcethe security policies. Such a control is nevertheless useful to detectunauthorized traffic in the MANET, and thus to alert the nodes along theroute from the source node to the destination node, avoiding that suchunauthorized traffic is routed further until these nodes receive aNOTIFICATION message (or a QUARANTINE message, as described later)generated as a consequence of the control performed by the DFC clients215 controlling the DFA clients 120 resident on nodes that are closer tothe node originating the unauthorized traffic.

Quarantine

As explained in the foregoing, each time a DFC client 215 detects or isinformed by other DFC clients 215 that the DFA client 120 resident on adirect neighbouring node violates the security policies, the DFC client215 puts the policy violator node in quarantine.

The schematic flowchart of FIG. 9 depicts the quarantine procedure, inan embodiment of the present invention.

Firstly, the DFC client 215 increments a first counter (hereinafterreferred to as “FW counter”) that is used to keep track of the number ofconsecutive times that the considered DFA client 120, to be put inquarantine, has not properly enforced the security policies defined forthe MANET (block 905).

The DFC client 215 then checks if the value of the FW counter for theconsidered DFA client 120 has reached a predetermined threshold FwThr(block 910): in the affirmative case (exit branch Y of block 910), theDFC client 215 starts the global repair procedure in respect of that DFAclient 120 (block 915), as described in detail later on: in such a case,the DFC client 215 preferably broadcasts a QUARANTINE message with aflag set to indicate that the global repair procedure has been startedfor that DFA client 120, so as to avoid that different DFC clients 215start the global repair procedure for the same DFA client 120.

Then, the DFC client 215 increments a second counter (hereinafterreferred to as the “source counter”), that is used to keep track of thenumber of consecutive times that the source node (having IP addressIP_S) originating the traffic that violates the security policies hasattempted to generate unauthorized traffic (block 920). The DFC client215 checks (block 925) if the value of the source counter has reached apredetermined threshold value SThr: in the affirmative case (exit branchY of block 925), the DFC client 215 starts the global repair procedure(block 930) for the source node having IP address IP_S, and sets therespective flag to be included in a QUARANTINE message that issuccessively broadcast, so as to avoid that other DFC clients 215 startthe global repair procedure in respect of that node.

The quarantine involves temporarily isolating the node hosting the DFAclient 120 that did not enforce the security policies. The node hostingthe DFC client 215 ceases announcing the violator node as its neighbourin HELLO messages it sends (block 935), and activates a third counter,hereinafter referred to as “Qtimer” (block 940). Then, the DFC client215 broadcasts a QUARANTINE message (block 945), so that the othernetwork nodes are made aware of the security policies violation, andremove from their routing tables the routes involving the violator node.Until the value of the timer Qtimer reaches the prescribed thresholdvalue (exit branch N of block 950), the DFC client 215 continues tobroadcast HELLO messages without announcing the violator node (955).When instead the value of the timer Qtimer reaches the preset thresholdvalue (exit branch Y of block 950), the DFC client 215 re-inserts thenode hosting the violator DFA client 120 into the HELLO messages itbroadcasts (block 960), and resets the time Qtimer (block 965): thequarantine is thus stopped, and the DFA client 120 that violated thesecurity policies is re-inserted in the routing tables of the MANETnodes.

In the schematic flowchart of FIGS. 10A and 10B the management of thealarm messages that have been mentioned in the foregoing and that areused in an embodiment of the present invention is depicted.

As mentioned in the foregoing, the NOTIFICATION message is broadcastedto all the MANET nodes whenever a DFC client 215, during the monitoringof the traffic on the controlled DFA client 120, detects a violation ofthe security policies defined for the MANET, and identifies the violatorDFA client 120 that has not enforced the security policies, but the DFCclient 215 cannot directly put the violator node in quarantine, becausethe violator node is not a next-hop thereof.

The purpose of the NOTIFICATION message is:

-   -   notifying to the other MANET nodes that a certain DFA client 120        has not properly enforced the security policies;    -   ask the neighbouring nodes to put the violator node in        quarantine; and    -   ask the nodes that are along the route from the source node to        the destination node to temporarily apply the violated security        policies.

The structure of the NOTIFICATION message is depicted in FIG. 11; themessage includes:

-   -   a field 1105 for carrying the IP address IP_S of the source node        originating the data packets violating the security policies;    -   a field 1110 for carrying the IP address IP_D of the destination        node of the data traffic;    -   a field 1115 for carrying the IP address IP_DFA of the node        where the DFA client 120 that has not enforced the security        policies resides;    -   a field 1120 for carrying an identifier ID of the traffic        session;    -   a field 1125 for carrying an identifier RuleID of the security        policy (firewalling rule) that has been violated; and    -   a field 1130 for carrying the IP address IPNotification of the        node where the DFA client 120 resides that is controlled by the        DFC client 215 and that has detected traffic not compliant with        the security policy identified by the identifier RuleID.

Referring to FIG. 10A, each DFC client 215, upon receiving an alarmmessage, checks (block 1005) if the received message is a message of thetype NOTIFICATION. In the affirmative case (exit branch Y of block1005), the DFC client 215 checks if the node where it resides is adirect neighbour of the node where the violator DFA client 120 resides(the node whose IP address IP_DFA is contained in the field 1115) (block1010): in the affirmative case (exit branch Y of block 1010), the DFCclient 215 checks whether it has already put the violator node inquarantine (block 1015). If the violator node has already been put inquarantine (exit branch Y of block 1015), the DFC client 215 stopspropagating the NOTIFICATION message (block 1020). If on the contrarythe violator node has not been put in quarantine yet (exit branch N ofblock 1015), the DFC client 215 starts the quarantine procedure inrespect of the violator node (block 1025) and then it stops propagatingthe NOTIFICATION message (block 1020).

If the node where the DFC client 215 that received the NOTIFICATIONmessage is not a direct neighbour of the violator node (exit branch N ofblock 1010), then the DFC client 215 checks whether the node where itresides is on the route from the source node (IP address IP_S) to thedestination node (IP address IP_D), by assessing if the IP address ofthe node where it resides coincides with the address IPNotificationcontained in the field 1130 of the received message (block 1030). In theaffirmative case (exit branch Y of block 1030), the DFC client 215assesses whether it has already applied the security policy (firewallingrule) that has been violated (identified by the identifier RuleIDcontained in the field 1125 of the received message) (block 1035). If ithas (exit branch Y of block 1035), then it means that the DFC client 215has already received previous NOTIFICATION alarm messages, possibly byother DFC clients 215 that control it, and thus it stops furtherpropagating the NOTIFICATION message (block 1020). Differently (exitbranch N of block 1035), it applies the violated security policy(identified by the identifier Rule ID) (block 1040), and stops routingfurther data packets of the type identified by the identifier IDcontained in the field 1120 of the received message. The DFC client 215then checks (block 1045) if it already received previous NOTIFICATIONmessages in respect of the same traffic session identifier by theidentifier ID: in the negative case (exit branch N of block 1045), itpropagates further the message (block 1050), otherwise (exit branch Y ofblock 1045) it stops propagating the message (block 1020).

If the DFC client 215 assesses that the node where it resides is not onthe route from the source node to the destination node (exit branch N ofblock 1030), then it checks whether it already received previousNOTIFICATION messages for the same traffic session (block 1045); in theaffirmative case (exit branch Y of block 1045), it stops propagating themessage (block 1020), otherwise (exit branch N of block 1045), itfurther propagates the message (block 1050).

The QUARANTINE message is broadcasted to all the MANET each time a DFCclient 215 detects that a controlled DFA client 120 has not enforced thesecurity policies, and, being the node where it resides a next-hop ofthe node where the violator DFA client 120 resides, it directly puts thelatter in quarantine. The QUARANTINE message is also broadcasted by aDFC client 215 that, having received a NOTIFICATION message, recognizesto be a direct neighbour of the violator DFA client 120, and thus putsthe latter in quarantine.

The purpose of the QUARANTINE message is that of informing the othernodes that a certain node has been put in quarantine, and thus it allowskeeping the counters FW counter and source counter aligned.

The structure of the QUARANTINE message is depicted in FIG. 12; themessage includes:

-   -   a field 1205 for carrying the IP address IP_S of the source node        originating the data packets violating the security policies;    -   a field 1210 for carrying the IP address IP_D of the destination        node of the data traffic;    -   a field 1215 for carrying the IP address IP_DFA of the node        where the DFA client 120 that has not enforced the security        policies resides;    -   a field 1220 for carrying an identifier ID of the traffic        session;    -   a field 1225 for carrying an identifier RuleID of the security        policy (firewalling rule) that has been violated;    -   a field 1230 for carrying a flag CGR (“Client Global Repair”)        used to notify to the other nodes that a global repair procedure        has been started for the violator DFA client 120 residing on the        node of address IP_DFA; and    -   a field 1235 for carrying a flag SGR (“Source Global Repair”)        used to notify to the other nodes that the global repair        procedure has been started for the source node of address IP_S        that generated the unauthorized traffic.

Referring to FIG. 10B, the DFC client 215, upon verifying that receivedalarm message is not a NOTIFICATION message (exit branch N of block1005), checks whether the message is a QUARANTINE message (block 1055).In the affirmative case (exit branch Y of block 1055) it checks whetherthe node where it resides is a direct neighbour of the node where theviolator DFA client 120 resides, identified by the address IP_DFAcontained in the field 1215 of the received message (block 1060): ifthis is not the case (exit branch N of block 1060), the DFC client 215checks whether it already received previous QUARANTINE messages for thesame session identified by the session identifier ID contained in thefield 1220 of the received message (block 1065), in which case (exitbranch Y of block 1065) it stops propagating the QUARANTINE message(block 1070); if no QUARANTINE messages were previously received (exitbranch N of block 1065), the DFC client 215 increases the counters FWcounter and source counter (block 1075), stops forwarding theNOTIFICATION messages (block 1080) received/generated in respect of thesame session identified by the identifier ID, and propagates theQUARANTINE message to the other nodes (block 1081).

If the DFC client 215 instead realizes to be a direct neighbour of thenode where the violator DFA client 120 resides (exit branch Y of block1060), it checks whether the violator node has already been put inquarantine (block 1083): if it has not (exit branch N of block 1083),the DFC client 215 puts the violator node in quarantine (connector B andblock 1025), otherwise (exit branch Y of block 1083) it stopspropagating the QUARANTINE message (block 1070).

ALERT alarm messages, differently from the NOTIFICATION and QUARANTINEmessages, are sent only to the next hops of the node hosting a DFCclient 215 each time the latter is more than 3 hops far from the sourcenode of the unauthorized traffic, and only in case the DFC client 215 isnot able to identify which is the DFA client 120 that has not enforcedthe security policies. The ALERT message is sent to inform a DFA client120 controlled by the DFC client 215 about the presence of unauthorizedtraffic along the route from the source node to the destination node, sothat the DFA client 120 can block the unauthorized traffic.

The structure of the ALERT message is depicted in FIG. 13; the messageincludes:

-   -   a field 1305 for carrying the IP address IP_S of the source node        originating the data packets violating the security policies;    -   a field 1310 for carrying the IP address IP_D of the destination        node of the data traffic;    -   a field 1315 for carrying the IP address IP_DFA of the node        where the DFA client 120 that has not enforced the security        policies resides;    -   a field 1320 for carrying an identifier ID of the traffic        session;    -   a field 1325 for carrying an identifier RuleID of the security        policy (firewalling rule) that has been violated;    -   a field 1330 for carrying the IP address IP_Alert of the node        hosting the DFA client 120 controlled by the DFC client 215 and        that detected the presence of unauthorized traffic.

Upon receiving an ALERT message (exit branch N of block 1055), the DFCclient 215 checks whether it is on the route from the source node to thedestination node, by comparing its own IP address with the addressIP_Alert contained in the field 1330 of the received message (block1085). If the two addresses coincide (exit branch Y of block 1085), thenthe DFC client 215 ascertains whether it has already applied theviolated security policies (identified by the identifier RuleID) (block1087). If not (exit branch N of block 1087), the security policy isapplied (block 1089), otherwise it means that previous ALERT messageswere already received for the same session, and the message is thusignored (block 1091). In both cases, the DFC client 215 waits for thenext NOTIFICATION and QUARANTINE messages (block 1093). A DFC client 215that, upon receiving the ALERT message, assesses not to be along theroute from source node to the destination node (exit branch N of block1085) ignores the ALERT message (block 1091) and keeps on listening nextNOTIFICATION and QUARANTINE messages (block 1093).

Global Repair Mechanism

The global repair mechanism involves the intervention of the DFC server205, which is responsible of centrally managing the DFC mechanism, eachtime a stronger countermeasure against the security policies violatornodes is requested, in respect of nodes that have repeatedly violatedthe security policies, not enforcing them properly. The global repairmechanism is used whenever the quarantine did not succeed.

The global repair mechanism may involve the exclusion from the MANET ofa node where the violator DFA client 120 resides, identified during thelocal repair procedure; the node excluded from the MANET may berequested to re-authenticate itself in order to be re-admitted to theMANET.

The global repair procedure in respect of a generic network node isstarted by the first DFC client 215 whose counter FW counter for thatnode reaches the predetermined threshold: in such a case, the DFC client215, during the local repair procedure, sets the CGR flag in theQUARANTINE message it broadcasts. The DFC clients 215 that receive theQUARANTINE message with the CGR flag set are informed of the fact thatsome node already started the global repair procedure, and thus theyreset the respective counters FW counter in respect of the same DFAclient 120.

The global repair procedure involves the transmission to the DFC server205 of a GLOBAL REPAIR REQUEST message, whose structure is pictoriallyshown in FIG. 14A. The message, globally denoted 1400, includes:

-   -   a field 1405 for carrying the IP address IP_S of the source node        of the data packets that violate a certain security policy;    -   a field 1410 for carrying the IP address IP_DFA of the node        where the violator DFA client 120 resides, that has not enforced        the security policy; and    -   a field 1415 for carrying the identifier RuleID of the violated        security policy (firewalling rule).

Upon receiving a GLOBAL REPAIR REQUEST message, the DFC server 205verifies whether a violation actually occurred. This is done by aninteraction with the DFA server 110. The latter:

-   -   checks the correspondence between the security policy identified        by the identifier RuleID contained in the received GLOBAL REPAIR        REQUEST message, and one of the security policies in a list of        security policies configured for the MANET;    -   ensures that the security policy identified by the identifier        RuleID has actually been sent to the source node of the        unauthorized traffic and the node where the violator DFA client        120 resides, specified in the received GLOBAL REPAIR REQUEST        message (the DFA server 110 keeps a list of the active MANET        nodes, and, for each of them, an indication of the current        security policies (general and specific) applied by the node).

If the DFA server 110 finds that the DFA client 120 identified by the IPaddress IP_DFA in the received GLOBAL REPAIR REQUEST message actuallyviolated the security policies, the DFA server 110 removes the IPaddress IP_DFA of that node (and thus the firewalling rule defined forit) from its database. Then, the DFA server 110 sends to theauthentication server of the MANET the identifier IP_DFA of the node tobe de-authenticated. The DFA server 110 also sends to the DFC server 205a GLOBAL REPAIR ACCEPT message, by means of which it requests theexclusion of the node identified by the IP address IP_DFA from theMANET. The structure of the GLOBAL REPAIR ACCEPT message isschematically depicted in FIG. 14B: the message, globally denoted 1450,contains a field 1455 for carrying the IP address IP_DFA of the node tobe excluded from the list of DFC clients 215, and a field 1460 forcarrying a signature of the DFC server 205. The signature is included inthe GLOBAL REPAIR ACCEPT message by the DFC server 205, which then sendsit to the node that sent the GLOBAL REPAIR REQUEST message; the GLOBALREPAIR ACCEPT message is then broadcasted in the MANET, so that thenodes can exclude the node identified by the IP address IP_DFA, blockingany kind of traffic it generated, exception made for authenticationtraffic for the re-authentication of the node in the MANET. At the sametime, the DFA server 205 informs every node of the exclusion of the DFAclient 120 resident on the excluded node; this is done through theperiodic polling mechanism by which the DFA clients 120 get from the DFAserver 110 the security policies to be enforced.

The same global repair procedure is also applied when the counter sourcecounter reaches the predetermined threshold.

In addition to the detection of the improper enforcement of the securitypolicies, the present invention can also be used for detecting andcontrasting selfish nodes, which tend to participate to the MANET insuch a way that they only route their own data packets, discarding thedata packets originating from/directed to other nodes. Exploiting thesame mechanisms described in the foregoing (selection of the controlledDFA clients 120 and of the controller DFC clients 215, local and globalrepair mechanisms), it is possible to isolate the selfish nodes, therebypromoting cooperation between the nodes.

Referring to FIG. 2, each node acts as a controller (DFC client 215) ofa certain DFA client 120, through the constant monitoring of the trafficentering and exiting the controlled DFA client 120. In order to detectand manage a selfish behaviour of a controlled DFA client 120, thecontroller DFC client 215 checks that the packets related to the routingprotocol and the application-layer packets are properly routed(complying the security policies defined for the MANET).

In particular, referring to FIG. 15, for each data packet 1500 enteringand/or exiting a controlled DFA client 120, it is first assessed whetherthe packet complies with the security policies defined for the MANET(block 1505); in case of violation of the security policies (exit branchY of block 1505), this is managed as described in the foregoing, firstthrough the local repair mechanism (block 1510), and then through theglobal repair mechanism (block 1520), if the counters FW counter and/orsource counter have reached the predetermined threshold (block 1515). Ifthe packet complies with the security policies defined for the MANET(exit branch N of block 1505), the selfish node detection logic isapplied (block 1525): for each packet entering the controlled DFA client120, having destination IP address IP_D different from the IP addressIP_DFA of the node where the controlled DFA client 120 resides, thepresence of a corresponding packet exiting the node is checked by thecontroller DFC client 215. In case the entering packets are discarded(not let pass through), the controller DFC client 215 decrees a selfishbehaviour (exit branch Y of block 1525), and applies a simplified localrepair mechanism (1530): the controller DFC client 215 increases adropped packets counter associated with the controlled DFA client 120;if the dropped packets counter reaches a selfish node detectionthreshold (set by the controller DFC client 215 according to thesecurity policies of the MANET), then the controller DFC client 215broadcasts a SELFISH NODE QUARANTINE message, schematized in FIG. 16 andincluding:

-   -   a field 1605 carrying an IP address IP_SELF of the selfish node;    -   a field 1610 carrying the MAC address of the selfish node;    -   a field 1615 carrying the identifier RuleID of the violated        firewalling rule; and    -   a field 1620 carrying a flag indicating whether the global        repair procedure has already been started.

Each DFC client 215 which, upon receiving the SELFISH NODE QUARANTINEmessage, realizes to be a direct neighbour of the selfish node, puts thelatter in quarantine, stopping to announce the selfish node as itsneighbour in the HELLO messages, and ignores routing messages comingfrom the selfish node. In this way, the distant DFC clients, notreceiving information about the selfish node, remove it from theirrouting tables. Similarly to the case of violation of a securitypolicies described above, the quarantine is temporary, and lasts apredetermined time (for example, a timer is used for this purpose),after which the nodes that are direct neighbours of the selfish noderestart announcing the selfish node as their neighbour; the selfish nodeis thus re-inserted in the routing tables of all the nodes of the MANET.

The SELFISH NODE QUARANTINE message is also exploited to keep thecounters FW counter of the controller DFC clients aligned; thesecounters are used, as described above, for handling the global repairprocedure (a same counter is used for starting the global repairprocedure, irrespective of whether a violation of a security policy or aselfish behaviour are detected).

The invention has been here described making reference to an exemplaryembodiment thereof; those skilled in the art will recognize that severalmodifications to the described embodiment, as well as other embodimentsare conceivable, without departing from the scope of the invention,defined in the appended claims.

1-28. (canceled)
 29. A method of enforcing security policies in a mobilead-hoc network, comprising: entrusting at least one first network node,along a data traffic route from a data traffic origin node to a datatraffic destination node, with enforcing of predefined security policieson said data traffic; and entrusting at least one second network node,distinct from said first network node, with control of the enforcementof the security policies by said first network node.
 30. The method ofclaim 29, wherein said at least one first network node comprises anetwork node being a direct neighbour of the origin node.
 31. The methodof claim 30, wherein said at least one first network node furthercomprises a network node being a direct neighbour of the destinationnode.
 32. The method of claim 29, further comprising: providing at leastone central security policies distribution server capable of beingconfigured to distribute the predefined security policies to the networknodes.
 33. The method of claim 29, comprising: having the at least onesecond network node control compliance with the predefined securitypolicies of data traffic passing through at least one third network nodealong said data traffic route.
 34. The method of claim 33, furthercomprising: having the at least one second network node selecting saidat least one third network node among a set of multipoint relay nodesthereof.
 35. The method of claim 34, wherein having the at least onesecond network node selecting the at least one third network nodecomprises selecting the at least one third network node among two ormore respective multipoint relay nodes as either: the multipoint relaynode through which a lowest number of nodes distant two hops can bereached; or in case two or more of the multipoint relay nodes of thesecond network nodes allow reaching a same, lowest number of nodesdistant two hops, the multipoint relay node that has in turn elected alowest number of multipoint relay nodes.
 36. The method of claim 35,wherein having the at least one second network node selecting the atleast one third network node further comprises: in case two or more ofthe multipoint relay nodes of the second network nodes have elected asame, lowest number of multipoint relay nodes, choosing the at least onethird network node at random among said two or more of the multipointrelay nodes of the second network node that have elected the lowestnumber of multipoint relay nodes.
 37. The method of claim 33, wherein,in case the at least one second network node is in a loop, selecting theat least one third network node comprises selecting, among themultipoint relay nodes of the second network node, the network nodethat, starting from the second network node and passing through a nodein the loop having lowest network address, allows reaching a first nodeannounced in a multipoint relay selector set in a transmission controlprotocol message.
 38. The method of claim 33, further comprising: incase the second network node detects a security policies violation:having the second network node ascertain whether the third network nodeis the first network node; if the third network node is the firstnetwork node, having the second network node undertake an actiondirected to at least temporarily exclude the first network node from thenetwork; if the third network node is not the first network node, havingthe second network node: identify the first network node, and in casesaid first network node is a direct neighbour of the second networknode, undertake an action directed to at least temporarily exclude thefirst network node from the network; in case said first network node isnot a direct neighbour of the second network node, or the first networknode cannot be identified, broadcast an alarm message capable of beingadapted to inform the other network nodes of the security policiesviolation.
 39. The method according to claim 33, further comprising:having the second network node controlling whether the third networknode properly routes data traffic entering thereinto; and in thenegative case, having the second network node undertake an action totemporarily exclude the third network node from the network.
 40. Themethod of claim 39, wherein controlling whether the third network nodeproperly routes data traffic entering thereinto comprises: having thesecond network node ascertain that, for each data packet entering thethird network node and destined to a destination network node differentfrom the third node, there is a corresponding data packet exiting thethird node.
 41. A system for enforcing security policies in a mobilead-hoc network, comprising: at least one first network node, along adata traffic route from a data traffic origin node to a data trafficdestination node, entrusted with enforcing of predefined securitypolicies on data traffic; and at least one second network node, distinctfrom said first network node, entrusted with control of enforcement ofsecurity policies by said first network node.
 42. The system of claim41, wherein said at least one first network node comprises a networknode being a direct neighbour of the origin node.
 43. The system ofclaim 42, wherein said at least one first network node further comprisesa network node being a direct neighbour of the destination node.
 44. Thesystem of claim 41, further comprising at least one central securitypolicies distribution server capable of being configured to distributethe predefined security policies to the network nodes.
 45. The system ofclaim 41, wherein the at least one second network node is capable ofbeing configured to control a compliance with the predefined securitypolicies of the data traffic passing through at least one third networknode along said data traffic route.
 46. The system of claim 45, wherein:the at least one second network node is capable of being adapted toselect the at least one third network node among a set of a multipointrelay nodes thereof.
 47. The system of claim 46, wherein said at leastone second network node is capable of being adapted to select the atleast one third network node among two or more respective multipointrelay nodes as either: the multipoint relay node through which a lowestnumber of nodes distant two hops can be reached; or in case two or moreof the multipoint relay nodes of the second network nodes allow reachinga same, lowest number of nodes distant two hops, the multipoint relaynode that has in turn elected a lowest number of multipoint relay nodes.48. The system of claim 47, wherein said at least one second networknode is capable of being adapted to select the at least one thirdnetwork node randomly among two or more of the multipoint relay nodes ofthe second network node that have elected the lowest number ofmultipoint relay nodes.
 49. The system of claim 46, wherein, in case theat least one second network node is in a loop, the second network nodeis capable of being adapted to select, among the multipoint relay nodesof the second network node, the network node that, starting from thesecond network node and passing through a node in the loop having lowestnetwork address, allows reaching a first announced node announced in amultipoint relay selector set in a transmission control protocolmessage.
 50. The system of claim 45, wherein: in case the second networknode detects a security policies violation, the second network node iscapable of being adapted to assess whether the third network node is thefirst network node, and: in the affirmative case, to undertake an actiondirected to at least temporarily exclude the first network node from thenetwork; in the negative case: to identify the first network node; incase said first network node is a direct neighbour of the second networknode, undertake an action directed to at least temporarily exclude thefirst network node from the network; and in case said first network nodeis not a direct neighbour of the second network node, or the firstnetwork node cannot be identified, to broadcast an alarm message capableof being adapted to inform the other network nodes of the securitypolicies violation.
 51. The system according to claim 45, wherein thesecond network node is further capable of being adapted to controlwhether the third network node properly routes data traffic enteringthereinto, and, in the negative case, to undertake an action totemporarily exclude the third network node from the network.
 52. Thesystem of claim 51, wherein the second network node is capable of beingadapted to ascertain that, for each data packet entering the thirdnetwork node and destined to a destination network node different fromthe third node, there is a corresponding data packet exiting the thirdnode.